Welcome @ntnn!

It looks like this is your first PR to kubernetes-sigs/multicluster-runtime 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/multicluster-runtime has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

The committers listed above are authorized under a signed CLA.

• ✅ login: ntnn / name: Nelo-T. Wallus (04d1112)

@ntnn very cool provider!
cc @embik

I know its a bit late for this idea (a lot of work has went into this PR!), but what if you added this functionality to the existing kubeconfig provider?
Seems like there is a decent amount of similar code, the only main difference is where we watch for kubeconfig. If it doesn't make sense, that's totally cool.

Was thinking about maybe changing the kubeconfig provider options to use functions instead of config struct, then could be something like:

p, err := kubeconfig.New(
   kubeconfig.WithFileWatcher(fileWatchConfigs...),
   kubeconfig.WithSecretWatcher(secretWatchConfigs...)
)

What do you all think of that?

Hi @FourFifthsCode !

Thanks! Imho most overlap is how to engange/disengage clusters and that is common between all providers.

Personally I was hoping to keep providers simpler and to instead use a "meta" provider to use multiple providers.
That's why I PR'd the chain provider - however that comes with the problem of shadowing clusters if two clusters yield the same clusterName.
For that reason @embik and I landed on the multi provider, which prevents the shadowing but requires a prefix for each provider.

If a provider accepts multiple different sources the same problem arises and the clusterName would either have to be prefixed or just logging an error - which is what I currently do here in the file provider, but the file provider is only meant to make it possible to inject some kubeconfigs when working on a controller.

I think a library with a generic provider that handles the common management of engaging/disengaging clusters would be great to simplify writing further providers.

@ntnn yeah, I think what you said makes a lot of sense! Multi-provider and some more shared code sounds great!

LGTM label has been added.

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: embik, ntnn

The full list of commands accepted by this bot can be found here.

The pull request process is described here